Policy scope management

ABSTRACT

The appropriate scoping of an access policy can be determined using the observed access and usage of various resources covered under that policy. Information about access requests received over a period of time can be logged, and actions represented in the log data can be mapped to the permissions of the access policy. A new access policy can be generated that includes grant permissions only for those actions that were received and/or granted during the monitored period of time. The new policy can be processed using policy logic to ensure that changes in permission comply with rules or policies for the target resources. The new policy can be at least partially implemented, or can be provided to an authorized user, who can choose to adopt or deny the new policy, or to accept some of the recommendations for modifying the current policy.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation application and claims priority toU.S. patent application Ser. No. 15/923,832, filed Mar. 16, 2018, ofwhich is incorporated by reference herein in its entirety.

BACKGROUND

Users are increasingly performing tasks using remote computingresources, often referred to as part of “the cloud.” This has manyadvantages, as users do not have to purchase and maintain dedicatedhardware and software, and instead can pay for only those resources thatare needed at any given time, where those resources typically will bemanaged by a resource provider. Users can perform tasks such as storingdata to various types of resources offered by a resource provider. Theuser often will have rules and policies regarding access to the userdata, which may be in addition to any access policies of the resourceprovider. While providing a robust and flexible policy frameworkprovides capabilities users desire, the complexity can result inpolicies that do not perform as expected. Further, the complexity canlead to users being granted different permissions than required orintended due in large part to the difficulty in determining thepermissions that should actually be granted to a particular set ofusers.

BRIEF DESCRIPTION OF THE DRAWINGS

Various embodiments in accordance with the present disclosure will bedescribed with reference to the drawings, in which:

FIG. 1 illustrates components of an example system for managing policyscope that can be utilized in accordance with various embodiments.

FIGS. 2A and 2B illustrate an example approach to dynamically scopingpolicy permissions based on observed activity that can be utilized inaccordance with various embodiments.

FIG. 3 illustrates components of an example resource environment thatcan be utilized in accordance with various embodiments.

FIG. 4 illustrates an example process for monitoring access data under apolicy that can be utilized in accordance with various embodiments.

FIG. 5 illustrates an example process for recommending an access policyusing monitored access data that can be utilized in accordance withvarious embodiments.

FIG. 6 illustrates example components of a computing device that can beused to implement aspects of various embodiments.

DETAILED DESCRIPTION

In the following description, various embodiments will be described. Forpurposes of explanation, specific configurations and details are setforth in order to provide a thorough understanding of the embodiments.However, it will also be apparent to one skilled in the art that theembodiments may be practiced without the specific details. Furthermore,well-known features may be omitted or simplified in order not to obscurethe embodiment being described.

Approaches described and suggested herein relate to the management ofaccess and actions with respect to data and resources in an electronicenvironment. In particular, various embodiments provide for the scopingof policies, such as access policies, based upon observed access andusage of various resources covered under those policies. An initialaccess policy may be implemented to determine whether to grant accessrequests received over a period of time. Information about accessrequests received over that period of time can be logged, then analyzedto determine patterns of access to the corresponding resources. Actionsrepresented in the log data can be mapped to the permissions of theaccess policy, and permissions that were utilized to grant access overthat period can be determined. A new access policy can be generated thatincludes grant permissions only for those actions that were receivedand/or granted during the monitored period of time. The new policy canbe processed using policy logic, such as to ensure that any changes inpermission result in a narrowing of the scope of permissions, or thatany increase in scope does not violate other permissions or rules, amongother such options. The new policy can then be provided to an authorizeduser as a recommendation that provides for modified scoping ofpermissions. The user can then choose to adopt the new policy, or canchoose to accept at least some of the recommendations for narrowing thecurrent policy, among other such options.

Various other such functions can be used as well within the scope of thevarious embodiments as would be apparent to one of ordinary skill in theart in light of the teachings and suggestions contained herein.

FIG. 1 illustrates an example system 100 that can be utilized toimplement aspects of the various embodiments. In this example, a policymanager 108 can manage policies to be applied to, and enforced for,various electronic resources 112. Policies can be applied to otherresources or entities as well as discussed elsewhere herein, as mayinclude users or organizations, among other such options. The policiesin some embodiments include access policies or trust policies thatdefine permissible actions that can be taken by specific users orentities with respect to the applicable electronic resources, orapplications or services supported by those resources. The electronicresources can include any physical or virtual resources capable ofreceiving, storing, processing, and/or transmitting data electronically,as may include servers, databases, virtual machines, and the like. Thepolicy manager 108 can store the policies to a policy data store 110, orother such location, and ensure that the relevant policies are enforcedat least with respect to access to the relevant resources 112.

The policies can be received from a variety of different sources. Forexample, a customer can provide a customer-generated orcustomer-obtained policy through a customer console 102 or other suchmechanism, which can call into an appropriate application programminginterface (API) or other element of an interface layer 106 in order toprovide the policy to the policy manager 108. A customer can also usesuch a mechanism to modify or delete such a policy, among other suchoptions. In some instances the policy might be generated automaticallyor through a software mechanism such as a policy generator 104, whichcan be under control of a provider of the resources 112 or anotherauthorized entity. If at least a subset of the resources is containedwithin a resource provider environment or multi-tenant environment, thepolicy generator 104 may be internal and/or external to that environmentin different embodiments.

As mentioned, it can be difficult to properly generate, update, and/orconfigure policies to properly manage access by a variety of users to avariety of resources storing different types of data and performingdifferent types of actions. Various users will want the ability tocreate precise access control policies, but this flexibility comes atthe cost of added complexity, which makes it more likely that thepolicies will not be configured properly in all instances. Variousembodiments provide a rich policy language that provides for a largevariety of functionality, but the language is not complete and it can bedifficult for users to understand all the various constructs of thepolicy language. This can lead to potential problems such as incorrectscoping of a policy. As used herein, “scoping” refers to determining therange or “scope” of permissions granted to specific users, groups orusers, or types of users under a specific policy. In at least someembodiments, each user would be granted only the permission that arerequired by the user, and intended to be granted to that user under thepolicy, and would be denied any other permission that is otherwiseavailable to be granted under the policy. As mentioned, however, thecomplexity of the policies and the applicable resource environment, aswell as the potential for a large number of users of many differenttypes, can make proper scoping difficult at best.

Accordingly, approaches in accordance with various embodiments canprovide a mechanism for dynamically adjusting the scope of permissionsgranted under a policy based at least in part upon the type of activitymonitored with respect to the policy. This can include, for example,utilizing an activity monitor 116 or other such system or service thatcan cause event data, or other such information, to be written to a logdata store 118 or other such repository in response to an action beingperformed, request being submitted, or detection of another suchoccurrence with respect to the monitored resources 112. The actions caninclude any relevant actions, such as the reading or writing of a dataobject to a respective data store. The information can include, or belinked to, the policy under which the permission to perform that actionwas granted. In other embodiments, the data might instead be linked tothe user or resource, and the applicable policy can subsequently bedetermined using policy data for the user or resource, among other suchoptions. In this way, any actions taken under permissions granted by aspecific policy over a period of time will be reflected in the loggeddata.

A system or service such as a policy scope monitor 120 can periodically,or at any other appropriate time, analyze the event data in the logrepository 118 to determine whether any adjustments may be recommendedto the scope of the policy based at least in part upon the determinedactions or events. For example, a given user might have been grantedfull access under the policy, which might include permission to performnine different types of action. Over a period of time, it might bedetermined that the identified user only utilized three of thosepermissions. Accordingly, it could be recommended in at least someembodiments for the policy to be adjusted to only maintain thepermissions for those three types of actions, and withdraw the other sixtypes of permissions. Such an approach can provide a type of leastprivileged access, where it is desired, for example, to keep the scopeof the permissions restricted to only those needed by any particularusers. In some embodiments this adjustment could be made automatically,or in conjunction with an appropriate permission adjustment policy thatmight indicate various timings, priorities, or criteria for adjustingthe permissions granted under a policy. In at least some embodimentsthese adjustments may be made as recommendations, however, as a user maywant or need to keep a permission that is not used frequently, or atleast was not utilized over the respective monitoring period. There alsocan be various policies or criteria used for recommending permissions towithdraw, such as where certain types of users always maintain certaintypes of permissions, such as read permissions and the like. Thechanging of permissions in some embodiments can be approved by the usersthemselves, while in other embodiments the changes will be approved by apolicy administrator or other such entity.

In such a process, policies can continue to be provided usingconventional approaches. For example, a user can submit a policy througha customer console 102, which can be received to the resource providerenvironment 122 and directed to a policy manager 108 or other suchsystem or service. The policy manager 108 can work with one or morepolicy evaluators 114, or policy logic analyzers, to attempt to validatethe policy with respect to the targeted resources 112, and ensure thatthe policy complies with all relevant policy guidelines, rules, andcriteria, as may be set by the customer, the resource provider, oranother such entity. The policy, if approved, can then be stored to apolicy data store 110 or other such location for use in evaluatingfuture access requests for the relevant resources 112.

Once approved, the policy can be used to grant permission to performvarious actions with respect to the corresponding resources. Requestsfor access can be evaluated, whether by the policy manager 108 or aseparate resource manager or access manager (not shown), among othersuch options. At least for access that is permitted, information for theaccess can be stored to the log data store 118. The policy scope monitor120 can then access the log information for a relevant time period (orall information in some embodiments) to obtain information about he setof permissions that were granted and executed under the policy. Asmentioned, this can include information about the types of permissionsexecuted by the various users over that period of time. The policy scopemonitor 120 can then create one or more recommendations for a new orupdated policy that corresponds more closely to the actual usage ofresources under the policy. These permissions could include accessgranted to services, or users to actions, among other such options. Ifthe permissions that are granted are not used within a given timeperiod, this can be potentially indicative that certain permissions areextraneous, or are no longer required, for the customers for theirintended usage. In some embodiments the recommendations will indicatechanges to scope that may be made to an existing policy, while in otherembodiments the recommendation may include a new policy that is based atleast in part upon the recommended changes in scope. The new policy insome embodiments can strictly reduce the access allowed in the originalpolicies, or earlier versions of the policies, based on the usagepattern, and does not remove any denies specified in the policy. In someembodiments the removals of one or more denies may be recommended basedupon received requests as well, but those may require at least somelevel or type of approval by an authorized entity. As mentioned, instill other embodiments the scope can be increased, denied, or acombination thereof based at least in part upon the monitored activityover the relevant period(s) of time.

In some embodiments the new policy is presented to the customer, such asthrough the customer console 102, as a recommendation. The customer, oran authorized user, may then choose to accept the new policy in lieu oftheir original policy, or may select to discard the new policy. In otherembodiments the user may modify either the new or existing policy toinclude some of the recommended changes in scope, as well as topotentially make other adjustments to the policy. In some embodimentsthe generated policy can be reviewed by the policy evaluator 114 to notonly ensure that it meets all relevant policy requirements, but also toensure that the changes in scope are permissible. This can include, forexample, ensuring that the scope of permissions is reduced where anychanges are recommended, and that there is no inadvertent increasing inscope where such increasing is not permitted. The policy evaluator 114can also ensure that the new recommended policy does not unintentionallyrestrict access to any infrastructure that was previously allowed. Theevaluator can ensure that the policy still corresponds to the same setof resources, such as the same data stores, buckets, tables, queryservices, messaging topics, and the like. The permissions may alsorelate to individual data objects or other such components or servicesas known for use with access management policies. The event data canalso be logged from search services, request managers, API events, andother such occurrences as discussed and suggested herein.

FIGS. 2A and 2B illustrate an example recommendation that might beincluded in a new policy that can be provided in accordance with variousembodiments. In the example set of permissions 200 indicated in FIG. 2A,a user (or type of user) is granted full access to a set of resources.In this example, full access refers to access granted for each of sixtypes of actions, including, read, write, execute, list, modify, andfull control access. There are various other types of access that can begranted as well as would be understood to one of ordinary skill in theart. Further, there can be different types of access granted forspecific sets or subsets of resources, or different types of resources,as discussed and suggested herein. In this example, the information alsoincludes a number of uses (or requests or executions) made by that user(or user type) over a given monitoring period. As illustrated, only twoof the six granted permissions were executed by that user over themonitoring period. Accordingly, the recommended policy permissionsillustrated in FIG. 2B have kept the granted permissions for the twotypes of actions that were actually used, but have denied access for thefour types of actions that were not actually used. As mentionedelsewhere herein, however there may be other information used todetermine the scope of the new access policy to be generated. This caninclude, for example, examining context information for the variousactions or requests for a policy over a period of time. Contextinformation can include any information associated with the request thatmay be useful in determining the proper permission scope, as may relateto a source address or location, type of user, date and time of therequest or action, and the like. This may help to provide permissionscorresponding to the context information, such as may permit (or deny)actions during a certain time of day, from a certain geographic region,or from a range or source addresses, among other such options.

Such an approach can help policy administrators and other such usersdetermine how the users are utilizing the various resources. Further,such an approach can help to properly scope the access granted tovarious users to more closely match the actual requirements. Asmentioned, these may be only recommendations in at least someembodiments, as the failure of a given user to perform a type of actionor request a type of access during a given period of time is notnecessarily indicative of a lack of need for that permission at a futureperiod of time. There may be a balancing in setting the length of themonitoring period, as longer periods of time may capture more types ofaccess, but can also reduce the speed at which changes in scope can beeffected using this process. In some embodiments the period of timemight be a week, while in other embodiments the period might be thirty,sixty, or ninety days. For high volume access, the period may besignificantly shorter, such as on the order of hours or minutes, amongother such options.

In one embodiment the generation of a new policy is performed using apredefined policy template created for a particular resource, or set ofresources. The API events executed for that resource over a period oftime can be determined, and those events can be mapped to theinformation extracted from the data log. The events can then be mappedto the respective policy statements, to determine the permission underwhich each event was granted access. The event will also be mapped orassociated with the appropriate resource, which at the object level mayinvolve scoping the permission down to a set of prefixes within a givenbucket or other such mapping. The mappings can then be used to generatethe new policy, such as an ASPN policy among other such options, whichcan be passed to the policy evaluator 114 to ensure proper down-scoping,so as to be less permissive in each case, with respect to the current orprevious policy. Policies can then be refined over time based at leastin part upon observed access patterns. Each new policy recommendationcan be presented to the authorized user in a number of different ways,such as through a customer console, email message, popup panel, and thelike. The user can then have the option of approving, denying, ormodifying each recommended policy, among other such options. This mayrequire the user to be authenticated in at least some embodiments toensure proper modification of the policy.

In at least some embodiments there may be a mechanism to roll back or atleast modify some of the changes in a new policy. For example, a userhaving a permission denied might be able to submit a request to have thepermission reinstated. If the user previously had that permissiongranted then in some embodiments the user may be able to automaticallyhave that permission reinstated, while in other embodiments a personsuch as a policy administrator or resource administrator might have toapprove the change. If this happens for a number of users of the sametype, or actions of the same type, then a similar roll back can beperformed automatically or suggested for performance, among other suchoptions. Further, there may be many different permissions and objectsfor a given policy, and in order to minimize user confusion orcomplexity the permissions and roll backs may be performed at certainlevels, such as at the bucket level instead of at the individual objectlevel, etc. For multiple objects, this may include collapsing on thecommon prefix or otherwise grouping in a human-readable fashion.

In at least some embodiments the recommended policies can be generatedat least in part using machine learning. For example, the accesspatterns of a set of user can be monitored over time and used to train amachine learning model. The access granted under a policy can bemonitored over a specific period of time, and that information processedusing the machine learning model to determine which permissions shouldbe maintained or denied for the policy. Such an approach not onlymaintains permissions for actions that were actually taken during theperiod, but also for permissions that are likely to be utilized based onthe machine learning model. Thus, even though a type of user may nothave performed a type of action, it can be learned that the user islikely to require that type of action at some point such that thepermission can be maintained even though the user did not perform thataction during the relevant time period.

In some embodiments, a policy administrator or other such entity canhave control over the amount of down scoping that is performed for aspecific policy. In embodiments where it is desirable to be asconservative as possible with respect to permissions, the new policymight maintain permissions only for those actions that were taken overthe previous period, with all others being denied. In other embodimentsrecommendations might be made, where the recommendations may becomestronger over time as certain actions are still not taken, or there mayonly be a certain subset of actions included in the recommendations. Alevel of scoping can also be provided to a machine learning component,which can make recommendations based upon likelihood of certain actionsor permissions being needed, among other such options. In at least someembodiments, machine learning can also be used to recommend additions tothe policy, or increases in certain permissions, that may be beneficialbased on observed behavior. In some embodiments such an approach mayalso submit recommendations to utilize alternative policies orpermissions, such as to change from bucket-level permissions toobject-level permissions, or to split a write permission into a putpermission and an update permission, among other such options.

When a new user or resource is added to the policy, the initial scopingcan be determined in a number of different ways. For example, theinitial access may be full access granted as discussed herein, with theeventual set of permissions being adjusted based upon actual usage. Insome embodiments an attempt will be made to classify or group the newuser or resource with similar users or resources, and apply scoping andpermissions similar to those applied for the other users or resources.In some embodiments an initial scope between the two may be granted,such as where the granted permissions are all granted but not all thedenied permissions for similar users or resources may be denied. Theremay be certain types of access that are less critical, or more critical,and these can be configured to either be more or less conservative whenit comes to initial restrictions in at least some embodiments.

In some embodiments a summary of the usage over the period can also bepresented to an authorized user with the recommended policy. This canhelp the user to determine whether the recommendations are based uponvalid usage data. For example, there may have been one or unauthorizeduser for whom permissions were granted, and those permissions should bedenied for the future policy. Similarly, there may be access granted tocertain users that is beyond what they should have been granted, or theresources covered under a given permission may be incorrect. There maybe various reasons why the historical usage data may be incorrect, and auser can choose to make modifications based on this, or in someembodiments can provide input to the system as to the invalid orunintended usage data, and the system can generate a new recommendedpolicy using only the valid and intended data over that period, alongwith potentially any other guidance or input from the user.

In some embodiments, the activity monitor or policy scope monitor mayalso generate alerts or notifications in response to activity that isdetermined to be suspicious or inadvertently granted. There may bevarious criteria specified that indicate improper usage or access, anddetection of any of these criteria may cause such a system or service togenerate a notification, or even an alert, based at least in part uponthe severity or type of action. A user may have the option of revokingor denying permission for the specific user, or can choose to modify thepolicy based upon one or more recommendations in the notification tocause that access permission to no longer be granted for that particularuser.

FIG. 3 illustrates an example environment 300 in which aspects of thevarious embodiments can be implemented. Such an environment can be usedto allocate resources, or resource capacity, for purposes such as toencode or provide media content, among other such options. These caninclude, for example, the resources 112 for which access requests arereceived in FIG. 1 . This can also include, for example, resources usedto provide the interface layer, managers, and monitoring system, amongother such options. In this example 300 a user is able to utilize aclient device 302 to submit requests across at least one network 304 toa resource provider environment 306. The client device can include anyappropriate electronic device operable to send and receive requests,messages, or other such information over an appropriate network andconvey information back to a user of the device. Examples of such clientdevices include personal computers, tablet computers, smart phones,notebook computers, and the like. The network 304 can include anyappropriate network, including an intranet, the Internet, a cellularnetwork, a local area network (LAN), or any other such network orcombination, and communication over the network can be enabled via wiredand/or wireless connections. The resource provider environment 306 caninclude any appropriate components for receiving requests and returninginformation or performing actions in response to those requests. As anexample, the provider environment might include Web servers and/orapplication servers for receiving and processing requests, thenreturning data, Web pages, video, audio, or other such content orinformation in response to the request.

In various embodiments, the provider environment may include varioustypes of electronic resources that can be utilized by multiple users fora variety of different purposes. In at least some embodiments, all or aportion of a given resource or set of resources might be allocated to aparticular user or allocated for a particular task, for at least adetermined period of time. The sharing of these multi-tenant resourcesfrom a provider environment is often referred to as resource sharing,Web services, or “cloud computing,” among other such terms and dependingupon the specific environment and/or implementation. In this example theprovider environment includes a plurality of electronic resources 314 ofone or more types. These types can include, for example, applicationservers operable to process instructions provided by a user or databaseservers operable to process data stored in one or more data stores 316in response to a user request. As known for such purposes, the user canalso reserve at least a portion of the data storage in a given datastore. Methods for enabling a user to reserve various resources andresource instances are well known in the art, such that detaileddescription of the entire process, and explanation of all possiblecomponents, will not be discussed in detail herein.

In at least some embodiments, a user wanting to utilize a portion of theresources 314 can submit a request that is received to an interfacelayer 308 of the provider environment 306. The interface layer caninclude application programming interfaces (APIs) or other exposedinterfaces enabling a user to submit requests to the providerenvironment. The interface layer 308 in this example can also includeother components as well, such as at least one Web server, routingcomponents, load balancers, and the like. When a request to provision aresource is received to the interface layer 308, information for therequest can be directed to a resource manager 310 or other such system,service, or component configured to manage user accounts andinformation, resource provisioning and usage, and other such aspects. Aresource manager 310 receiving the request can perform tasks such as toauthenticate an identity of the user submitting the request, as well asto determine whether that user has an existing account with the resourceprovider, where the account data may be stored in at least one datastore 312 in the provider environment. A user can provide any of varioustypes of credentials in order to authenticate an identity of the user tothe provider. These credentials can include, for example, a username andpassword pair, biometric data, a digital signature, or other suchinformation.

The resource provider can validate this information against informationstored for the user. If the user has an account with the appropriatepermissions, status, etc., the resource manager can determine whetherthere are adequate resources available to suit the user's request, andif so can provision the resources or otherwise grant access to thecorresponding portion of those resources for use by the user for anamount specified by the request. This amount can include, for example,capacity to process a single request or perform a single task, aspecified period of time, or a recurring/renewable period, among othersuch values. If the user does not have a valid account with theprovider, the user account does not enable access to the type ofresources specified in the request, or another such reason is preventingthe user from obtaining access to such resources, a communication can besent to the user to enable the user to create or modify an account, orchange the resources specified in the request, among other such options.

Once the user is authenticated, the account verified, and the resourcesallocated, the user can utilize the allocated resource(s) for thespecified capacity, amount of data transfer, period of time, or othersuch value. In at least some embodiments, a user might provide a sessiontoken or other such credentials with subsequent requests in order toenable those requests to be processed on that user session. The user canreceive a resource identifier, specific address, or other suchinformation that can enable the client device 302 to communicate with anallocated resource without having to communicate with the resourcemanager 310, at least until such time as a relevant aspect of the useraccount changes, the user is no longer granted access to the resource,or another such aspect changes.

The resource manager 310 (or another such system or service) in thisexample can also function as a virtual layer of hardware and softwarecomponents that handles control functions in addition to managementactions, as may include provisioning, scaling, replication, etc. Theresource manager can utilize dedicated APIs in the interface layer 308,where each API can be provided to receive requests for at least onespecific action to be performed with respect to the data environment,such as to provision, scale, clone, or hibernate an instance. Uponreceiving a request to one of the APIs, a Web services portion of theinterface layer can parse or otherwise analyze the request to determinethe steps or actions needed to act on or process the call. For example,a Web service call might be received that includes a request to create adata repository.

An interface layer 308 in at least one embodiment includes a scalableset of customer-facing servers that can provide the various APIs andreturn the appropriate responses based on the API specifications. Theinterface layer also can include at least one API service layer that inone embodiment consists of stateless, replicated servers which processthe externally-facing customer APIs. The interface layer can beresponsible for Web service front end features such as authenticatingcustomers based on credentials, authorizing the customer, throttlingcustomer requests to the API servers, validating user input, andmarshalling or unmarshalling requests and responses. The API layer alsocan be responsible for reading and writing database configuration datato/from the administration data store, in response to the API calls. Inmany embodiments, the Web services layer and/or API service layer willbe the only externally visible component, or the only component that isvisible to, and accessible by, customers of the control service. Theservers of the Web services layer can be stateless and scaledhorizontally as known in the art. API servers, as well as the persistentdata store, can be spread across multiple data centers in a region, forexample, such that the servers are resilient to single data centerfailures.

As mentioned, a customer of such a resource environment might have datathat is stored within the various data stores 316, as well ason-premises or other resources that may be outside the resource providerenvironment. The data can be managed using various policies that can beadministered by a policy manager 108 and stored in a policy database 110or other such location, as illustrated with respect to FIG. 1 . A policymanager in general can refer to a system, service, or component thatperforms tasks such as creating policies, associating policies withobjects, maintaining the associations, providing access to policies, andother such tasks, including those described elsewhere herein.

A policy import engine (or import/export engine) can be used in theresource provider environment, in conjunction with the policy manager,to import user-provided policies (or other policies generated outsidethe resource provider environment. A policy import engine can refergenerally to one or more systems, services, or components that areconfigured to perform tasks such as the importing and exporting ofpolicies, as well as determining whether those policies are able to beimported or exported, determining any conflicts, verifying ownership oraccess to various policies for import/export purposes, and the like. Insome embodiments one or more policy validators would be contained withinthe import engine or would be utilized by the policy import engine. Thepolicy import engine can determine the “cloud” policies, or policies ofthe resource provider environment, that apply to the bucket or otherlocation for which the user data is to be stored, and if the data and/oruser policies violate a policy associated with the bucket then thepolicy can be rejected. In some embodiments the policy manager workswith the authorization manager or other such components to determineauthorizations of the user in addition to policies to be applied to suchusage, and this information can be used for policy validation inaddition to other such tasks. This can include, for example, determiningwhich policies to apply for a specific task to be performed on behalf ofa user. In some embodiments, federated identities can be used, as may beprovided by various third parties, in order to determine the appropriateauthorizations, policies, etc. A data manager in some embodiments canmanage changes and access to the data, for example, which can beperformed in conjunction with an authorization manager, policy manager,etc. The data manager in some embodiments can monitor access to data, aswell as the policies applied and used to obtain the access, and can logthat information to an audit data store or other such location, enablingsubsequent auditing or verification as discussed elsewhere herein.

Once a policy is applied for a resource, or data stored by a resource,for example, the policy should be automatically enforced in theenvironment or on the storage platform where the data resides. Datamanagement may be based on factors such as compliance requirements,information technology (IT) governance, and security policies that applyfor a given user (i.e., enterprise). For example, a user can categorizea set of data as “log” data. The user can then manage all data thatfalls within this category using a specified set of policies. Datacategorized in a separate category, such as “financial critical” data,may be subject to a different set of management policies, as may bespecified by contract or otherwise. In order to provide the necessaryflexibility for users, policies can be able to be specified forindividual data objects. In the example of data on a file system, usersmanage permissions and metadata on individual files. Managing individualfiles, however, becomes increasingly difficult as the number of filesgrows. Similarly, users can be provided with the ability to write datamanagement policies based on data or other classifications specified atthe object level. Such ability enables users to exercise more controland better manage their data in the resource provider environment, asmay simplify data management. An example includes the writing of across-region replication policy for sensitive user data. The policymanager can provide access control to manage permissions for the adding,editing, and removal of policies for data objects stored in the datastores of the resource provider environment 26. The engine in at leastsome embodiments can ensure that only authorized users have the abilityto change policies on a data object, and that any changes are documentedand/or logged for future reference.

A user can provide various types of credentials in order to authenticatean identity of the user to the provider, which can be used for claimsvalidation and other operations discussed and suggested herein. Thesecredentials can include, for example, a username and password pair,biometric data, a digital signature, a signed certificate, or other suchinformation. These credentials can be provided by, or obtained from, anumber of different entities, such as an identity manager, identifyprovider, a key management service, a corporate entity, a certificateauthority, an identify broker such as a SAML provider, and the like. Insome embodiments, a user can provide information useful in obtaining thecredentials, such as user identity, account information, password,user-specific cryptographic key, customer number, and the like. Theidentity manager can provide the credentials, also stored to acredential data store, to the resource provider environment and/or tothe client device, whereby the client device can utilize thosecredentials to obtain access or use of various resources in the providerenvironment, where the type and/or scope of access can depend uponfactors such as a type of user, a type of user account, a roleassociated with the credentials, or a policy associated with the userand/or credentials, among other such factors. Although discussed asexternal to the resource provider environment, it should be understoodthat the identity manager can be a logical part of the resource providerenvironment in some embodiments.

FIG. 4 illustrates an example process 400 for monitoring accesspermitted under an access policy that can be utilized in accordance withvarious embodiments. It should be understood that for this and otherprocesses discussed herein that additional, fewer, or alternative stepscan be performed in similar or alternative steps, or in parallel, withinthe scope of the various embodiments unless otherwise stated. Further,although access policies are discussed for purposes of explanation, itshould be understood that various other types of policies or rules cantake advantage of advantages of the various embodiments as well. In thisexample, an access policy is received 402 that is to be enforced for aset of resources. As mentioned, the policy can be received from acustomer or third party, or may be generated by a provider managing theresources to be accessed, among other such options. Further, the set ofresources may be specified by the policy request, or may be learnedbased at least in part upon information associated with the request or acustomer account, etc. Before implementing the policy, the access policycan be validated 404 to ensure that the policy complies with any rulesor guidelines for access policies or the set of resources to beaccessed. This can include, for example, ensuring that any permissionsin the policy do not exceed the scope of permissions capable of beingprovided, as well as ensuring that the permissions are well defined andcomply with any policy formatting or other such requirements. In atleast some embodiments, the policy may be validated against permissionsgranted to users under the customer account to ensure that the policyreflects the appropriate permissions. Once any validations or other suchprocessing is performed successfully, the access policy can be caused406 to be implemented and enforced for the set of resources. Asmentioned, the resources are not limited to physical resources, such asservers and data storage devices, but can include other types ofresources such as virtual resources, services, and data objects as well,within the scope of the various embodiments.

Once the access policy is in place, a request can be received 408 foraccess to one or more of the set of resources. The request may specifythe resource(s), or the need for access to one or more of the resourcescan be determined upon analyzing the request, etc. The access policy canthen be consulted to determine 410 whether to grant the requestedaccess. As mentioned, this can include determining the type of accessrequested, then consulting the policy to see whether that type of accessis permitted for that user, type of user, device, or other source of therequest, at least with respect to the target resource(s). If it isdetermined 412 that the access is to be granted, then the access can bepermitted 414 per the request. Any limitations on the permissions can beenforced as discussed and suggested herein. If the access is not to begranted, then the access can be denied 416 and an error message or othernotification returned in at least some embodiments. Regardless ofwhether the access is granted in at least some embodiments, data for theaccess request can be written 418 to an access log or other suchlocation for subsequent analysis. As mentioned, the log data can bestored indefinitely or for a monitoring period of time, among other suchoptions.

FIG. 5 illustrates an example process 500 for recommending a new accesspolicy for a customer of a resource provider environment that can beutilized in accordance with various embodiments. In this example, a setof historical usage data can be obtained 502 with respect to a set ofresources, such as the log data generated in the example process 400 ofFIG. 4 . This can include information about each action or requestreceived, granted, and/or denied over at least a specified period oftime, where the access was to the set of resources and processed using aspecified access policy. It should be understood, however, that thehistorical data may include various other types of data, or data forother policies or resources as well, but that the data accessed will beof the type discussed herein. If not already known, the relevant accesspolicy can be determined 504 that was used to process the accessrequests over that period of time. The data can represent a set ofactions that were performed, and those actions can be mapped 506 topermissions of the access policy. For example, a writing of data to aresource might be analyzed to determine whether it was, or shouldproperly have been, granted access under a write permission, a modifypermission, a full control permission, or a put permission. Such aprocess can be used to determine at least which permissions wereutilized over that period of time, and in some cases the extent to whichthose permissions were utilized. The extent information may beparticularly useful when processing the information using machinelearning to recognize usage patterns or otherwise classify the variouspermission options.

In this example the utilized permissions can be utilized to generate 510a new access policy to be recommended for the set of resources. This caninclude, for example, obtaining a template policy for the resources andgranting permissions only where those permissions were utilized over themonitored period of time, although flexibility in the selection can beutilized in some embodiments as discussed and suggested herein. The newpolicy can also deny permissions where no action was performed orrequested, or where the action or request was denied, over thatmonitored period. This sets the scope of the policy to permit only thoseactions that were permitted over the monitored period of time. In someembodiments, the success of the action may be considered in determiningwhether to grant the permission. Before implementing or recommending thepolicy, at least some policy logic can be applied 512 to ensure properscoping of the permissions. This can involve ensuring that each changeto the new policy is permissible under relevant rules or policies forthe resources. In some embodiments, this can include ensuring that eachsuch change, relative to the prior policy, is at most of the same scopeor results in a smaller scope, and that no change inadvertently broadensthe scope. As mentioned, there may be embodiments where the scope isbroadened, or where certain permission scope is broadened for a policywhile others are decreased in scope, among other such options. Certainembodiments that utilize machine learning may also recommend alternativepermissions that may have different scope that may be permissible underthe relevant policy logic. A determination can be made 514 as to whetherthe new policy, or any portion of the policy, is able to beautomatically implemented. If so, the new policy, or permissibleportions, can be automatically applied 516 for enforcement with respectto the target resources. If the new policy cannot be automaticallyimplemented, or there are at least portions that cannot be implementedautomatically, the new policy can be recommended 518 to an authorizeduser or other such entity. This can be submitted through an interface,console, message, notification, or other such options. If it isdetermined 520 that the user accepts the new policy, then the new policycan be caused 522 to be implemented and enforced for the set ofresources for at least a future period of time. If it is determined thatthe user does not accept the policy, at least in its recommended form,then the policy can be discarded 524 or the user can be enabled tomodify the policy as discussed herein. This can include the useraccepting or rejecting specific recommendations in the policy, such asany of those that were not automatically implemented, which can then beprocessed using the policy logic and implemented upon user approval.

As mentioned, various functionality discussed and suggested herein canbe incorporated in one or more computing devices. FIG. 6 illustrates aset of basic components of an example computing device 600 that can beutilized to implement at least aspects of the various embodiments. Inthis example, the device includes at least one processor 602 forexecuting instructions that can be stored in a memory device or element604. As would be apparent to one of ordinary skill in the art, thedevice can include many types of memory, data storage orcomputer-readable media, such as a first data storage for programinstructions for execution by the at least one processor 602, the sameor separate storage can be used for images or data, a removable memorycan be available for sharing information with other devices, and anynumber of communication approaches can be available for sharing withother devices. The device may include at least one type of displayelement 606, such as a touch screen, electronic ink (e-ink), organiclight emitting diode (OLED) or liquid crystal display (LCD), althoughdevices such as servers might convey information via other means, suchas through a system of lights and data transmissions. The devicetypically will include one or more networking components 608, such as aport, network interface card, or wireless transceiver that enablescommunication over at least one network. The device can include at leastone input device 610 able to receive conventional input from a user.This conventional input can include, for example, a push button, touchpad, touch screen, wheel, joystick, keyboard, mouse, trackball, keypador any other such device or element whereby a user can input a commandto the device. These I/O devices could even be connected by a wirelessinfrared or Bluetooth or other link as well in some embodiments. In someembodiments, however, such a device might not include any buttons at alland might be controlled only through a combination of visual and audiocommands such that a user can control the device without having to be incontact with the device.

In this example, the computing device 600 can take the form of one ormore servers, or networked computing devices, that can provide variousmodules or process, or execute various applications, for performingaspects of various embodiments. In this example, the computing systemprovides a policy manager 108 that can receive, implement, and/orenforce policies for a set of resources. The computing system can alsoinclude a policy evaluator 114 that can validate any policy before thatpolicy is implemented. For new or updated policies, this can includeapplying policy logic to ensure that any change in permissions is morerestrictive, unless otherwise specified or permitted. Further, thecomputing system can include a policy scope monitor 120 that candetermine the usage granted under the various permissions and recommendnew or updated policies with a scope determined based at least in partupon the determined usage over the relevant period of time. Asmentioned, these and other processes can be performed on multiplemachines, and there can be other processes performed on such a machineas well within the scope of the various embodiments.

As discussed, different approaches can be implemented in variousenvironments in accordance with the described embodiments. As will beappreciated, although a Web-based environment is used for purposes ofexplanation in several examples presented herein, different environmentsmay be used, as appropriate, to implement various embodiments. Thesystem includes an electronic client device, which can include anyappropriate device operable to send and receive requests, messages orinformation over an appropriate network and convey information back to auser of the device. Examples of such client devices include personalcomputers, cell phones, handheld messaging devices, laptop computers,set-top boxes, personal data assistants, electronic book readers and thelike. The network can include any appropriate network, including anintranet, the Internet, a cellular network, a local area network or anyother such network or combination thereof. Components used for such asystem can depend at least in part upon the type of network and/orenvironment selected. Protocols and components for communicating viasuch a network are well known and will not be discussed herein indetail. Communication over the network can be enabled via wired orwireless connections and combinations thereof. In this example, thenetwork includes the Internet, as the environment includes a Web serverfor receiving requests and serving content in response thereto, althoughfor other networks, an alternative device serving a similar purposecould be used, as would be apparent to one of ordinary skill in the art.

The illustrative environment includes at least one application serverand a data store. It should be understood that there can be severalapplication servers, layers or other elements, processes or components,which may be chained or otherwise configured, which can interact toperform tasks such as obtaining data from an appropriate data store. Asused herein, the term “data store” refers to any device or combinationof devices capable of storing, accessing and retrieving data, which mayinclude any combination and number of data servers, databases, datastorage devices and data storage media, in any standard, distributed orclustered environment. The application server can include anyappropriate hardware and software for integrating with the data store asneeded to execute aspects of one or more applications for the clientdevice and handling a majority of the data access and business logic foran application. The application server provides access control servicesin cooperation with the data store and is able to generate content suchas text, graphics, audio and/or video to be transferred to the user,which may be served to the user by the Web server in the form of HTML,XML or another appropriate structured language in this example. Thehandling of all requests and responses, as well as the delivery ofcontent between the client device and the application server, can behandled by the Web server. It should be understood that the Web andapplication servers are not required and are merely example components,as structured code discussed herein can be executed on any appropriatedevice or host machine as discussed elsewhere herein.

The data store can include several separate data tables, databases orother data storage mechanisms and media for storing data relating to aparticular aspect. For example, the data store illustrated includesmechanisms for storing content (e.g., production data) and userinformation, which can be used to serve content for the production side.The data store is also shown to include a mechanism for storing log orsession data. It should be understood that there can be many otheraspects that may need to be stored in the data store, such as page imageinformation and access rights information, which can be stored in any ofthe above listed mechanisms as appropriate or in additional mechanismsin the data store. The data store is operable, through logic associatedtherewith, to receive instructions from the application server andobtain, update or otherwise process data in response thereto. In oneexample, a user might submit a search request for a certain type ofitem. In this case, the data store might access the user information toverify the identity of the user and can access the catalog detailinformation to obtain information about items of that type. Theinformation can then be returned to the user, such as in a resultslisting on a Web page that the user is able to view via a browser on theuser device. Information for a particular item of interest can be viewedin a dedicated page or window of the browser.

Each server typically will include an operating system that providesexecutable program instructions for the general administration andoperation of that server and typically will include computer-readablemedium storing instructions that, when executed by a processor of theserver, allow the server to perform its intended functions. Suitableimplementations for the operating system and general functionality ofthe servers are known or commercially available and are readilyimplemented by persons having ordinary skill in the art, particularly inlight of the disclosure herein.

The environment in one embodiment is a distributed computing environmentutilizing several computer systems and components that areinterconnected via communication links, using one or more computernetworks or direct connections. However, it will be appreciated by thoseof ordinary skill in the art that such a system could operate equallywell in a system having fewer or a greater number of components than areillustrated. Thus, the depiction of the systems herein should be takenas being illustrative in nature and not limiting to the scope of thedisclosure.

The various embodiments can be further implemented in a wide variety ofoperating environments, which in some cases can include one or more usercomputers or computing devices which can be used to operate any of anumber of applications. User or client devices can include any of anumber of general purpose personal computers, such as desktop or laptopcomputers running a standard operating system, as well as cellular,wireless and handheld devices running mobile software and capable ofsupporting a number of networking and messaging protocols. Such a systemcan also include a number of workstations running any of a variety ofcommercially-available operating systems and other known applicationsfor purposes such as development and database management. These devicescan also include other electronic devices, such as dummy terminals,thin-clients, gaming systems and other devices capable of communicatingvia a network.

Most embodiments utilize at least one network that would be familiar tothose skilled in the art for supporting communications using any of avariety of commercially-available protocols, such as TCP/IP, FTP, UPnP,NFS, and CIFS. The network can be, for example, a local area network, awide-area network, a virtual private network, the Internet, an intranet,an extranet, a public switched telephone network, an infrared network, awireless network and any combination thereof.

In embodiments utilizing a Web server, the Web server can run any of avariety of server or mid-tier applications, including HTTP servers, FTPservers, CGI servers, data servers, Java servers and businessapplication servers. The server(s) may also be capable of executingprograms or scripts in response requests from user devices, such as byexecuting one or more Web applications that may be implemented as one ormore scripts or programs written in any programming language, such asJava®, C, C# or C++ or any scripting language, such as Perl, Python orTCL, as well as combinations thereof. The server(s) may also includedatabase servers, including without limitation those commerciallyavailable from Oracle*, Microsoft*, Sybase® and IBM® as well asopen-source servers such as MySQL, Postgres, SQLite, MongoDB, and anyother server capable of storing, retrieving and accessing structured orunstructured data. Database servers may include table-based servers,document-based servers, unstructured servers, relational servers,non-relational servers or combinations of these and/or other databaseservers.

The environment can include a variety of data stores and other memoryand storage media as discussed above. These can reside in a variety oflocations, such as on a storage medium local to (and/or resident in) oneor more of the computers or remote from any or all of the computersacross the network. In a particular set of embodiments, the informationmay reside in a storage-area network (SAN) familiar to those skilled inthe art. Similarly, any necessary files for performing the functionsattributed to the computers, servers or other network devices may bestored locally and/or remotely, as appropriate. Where a system includescomputerized devices, each such device can include hardware elementsthat may be electrically coupled via a bus, the elements including, forexample, at least one central processing unit (CPU), at least one inputdevice (e.g., a mouse, keyboard, controller, touch-sensitive displayelement or keypad) and at least one output device (e.g., a displaydevice, printer or speaker). Such a system may also include one or morestorage devices, such as disk drives, magnetic tape drives, opticalstorage devices and solid-state storage devices such as random accessmemory (RAM) or read-only memory (ROM), as well as removable mediadevices, memory cards, flash cards, etc.

Such devices can also include a computer-readable storage media reader,a communications device (e.g., a modem, a network card (wireless orwired), an infrared communication device) and working memory asdescribed above. The computer-readable storage media reader can beconnected with, or configured to receive, a computer-readable storagemedium representing remote, local, fixed and/or removable storagedevices as well as storage media for temporarily and/or more permanentlycontaining, storing, transmitting and retrieving computer-readableinformation. The system and various devices also typically will includea number of software applications, modules, services or other elementslocated within at least one working memory device, including anoperating system and application programs such as a client applicationor Web browser. It should be appreciated that alternate embodiments mayhave numerous variations from that described above. For example,customized hardware might also be used and/or particular elements mightbe implemented in hardware, software (including portable software, suchas applets) or both. Further, connection to other computing devices suchas network input/output devices may be employed.

Storage media and other non-transitory computer readable media forcontaining code, or portions of code, can include any appropriate mediaknown or used in the art, such as but not limited to volatile andnon-volatile, removable and non-removable media implemented in anymethod or technology for storage of information such as computerreadable instructions, data structures, program modules or other data,including RAM, ROM, EEPROM, flash memory or other memory technology,CD-ROM, digital versatile disk (DVD) or other optical storage, magneticcassettes, magnetic tape, magnetic disk storage or other magneticstorage devices or any other medium which can be used to store thedesired information and which can be accessed by a system device. Basedon the disclosure and teachings provided herein, a person of ordinaryskill in the art will appreciate other ways and/or methods to implementthe various embodiments.

The specification and drawings are, accordingly, to be regarded in anillustrative rather than a restrictive sense. It will, however, beevident that various modifications and changes may be made thereuntowithout departing from the broader spirit and scope of the invention asset forth in the claims.

What is claimed is:
 1. A computer-implemented method comprising:receiving a first set of permissions relating to a set of resources in amulti-tenant environment; receiving a request to access one or moreresources of the set of resources; determining at least one type ofaccess corresponding to the received request; determining that the atleast one type of access is associated with the first set ofpermissions; adjusting at least one scope associated with the first setof permissions based on the at least one type of access; and generating,based at least in part on the adjusted scope, a second set ofpermissions, the second set of permissions maintaining permissionsgranted using the first set of permissions.
 2. The computer-implementedmethod of claim 1, further comprising: accessing, based at least in parton at least one scope associated with the second set of permissions, oneor more resources of the set of resources.
 3. The computer-implementedmethod of claim 1, further comprising: determining the at least onescope, associated with the first set of permissions, based at least inpart on at least one previous request to access at least one of the oneor more resources of the set of resources.
 4. The computer-implementedmethod of claim 1, wherein the first set of permissions includepermissions associated with at least one access request or at least oneauthentication request, the permissions defining a set of actionsassociated with at least one of the one or more resources of the set ofresources.
 5. The computer-implemented method of claim 1, furthercomprising: analyzing the second set of permissions to ensure that anychanges in permissions either result in a narrowing of the at least onescope, associated with the first set of permissions, or do not violateother permissions of the second set of permissions.
 6. Acomputer-implemented method, comprising: obtaining a first set ofpermissions applied to a set of resources in a multi-tenant environment;receiving a request to access one or more resources of the set ofresources; determining at least one type of access corresponding to thereceived request; determining that the at least one type of accesscorresponds to at least one scope associated with the first set ofpermissions; adjusting, based at least in part on the at least one typeof access, the at least one scope; and generating, based at least inpart on the adjusted scope, a second set of permissions, the second setof permissions maintaining permissions granted using the first set ofpermissions.
 7. The computer-implemented method of claim 6, furthercomprising: accessing, based at least in part on at least one scopeassociated with the second set of permissions, one or more resources ofthe set of resources.
 8. The computer-implemented method of claim 6,further comprising: obtaining a policy template for the set ofelectronic resources for use in generating the second set ofpermissions.
 9. The computer-implemented method of claim 6, furthercomprising: determining, based at least in part on the at least onescope associated with the first set of permissions, that the type ofaccess is a least privileged access; and analyzing the second set ofpermissions to ensure that at least one scope associated with the secondset of permissions is reduced.
 10. The computer-implemented method ofclaim 6, further comprising: determining at least one event executed forat least one resource of the one or more resources of the set ofresources, wherein the at least one event is mapped to at least onepermission of the first set of permissions to determine the permissionunder which the at least one event was granted access.
 11. Thecomputer-implemented method of claim 10, further comprising: determiningat least one scope associated with the second set of permissions,wherein the at least one scope associated with the second set ofpermissions is narrower than the at least one scope associated with thefirst set of permissions.
 12. The computer-implemented method of claim6, further comprising: wherein the second set of permissions does notremove denied permissions from the first set of permissions andmaintains access that was previously granted in the first set ofpermissions.
 13. The computer-implemented method of claim 6, furthercomprising: determining that the second set of permissions applies to aspecific task, the task performed on behalf of a user; and wherein atleast one scope of the second set of permissions is based at least inpart on the user.
 14. The computer-implemented method of claim 6,further comprising: validating the first set of permissions againstpermissible actions granted to at least one user associated with acustomer account to ensure that the first set of permissions reflect theappropriate permissions.
 15. The computer-implemented method of claim 6,further comprising: wherein a scope of the second set of permissionsgrants only permissions granted in the first set of permissions.
 16. Thecomputer-implemented method of claim 6, further comprising: detecting atleast one suspicious request; generating an alert for the at least onesuspicious request; and providing a recommendation to change at leastone permission of the first set of permissions to deny accesscorresponding to the at least one suspicious request.
 17. A system,comprising: at least one processor; and memory including instructionsthat, when executed by the at least one processor, cause the system to:obtain a first set of permissions applied to a set of resources in amulti-tenant environment; receive a request to access one or moreresources of the set of resources; determine at least one type of accesscorresponding to the received request; determine that the at least onetype of access corresponds to at least one scope associated with thefirst set of permissions; adjust, based at least in part on the at leastone type of access, the at least one scope; and generate, based at leastin part on the adjusted scope, a second set of permissions, the secondset of permissions maintaining permissions granted using the first setof permissions.
 18. The system of claim 17, wherein the instructionswhen executed further cause the system to: access, based at least inpart on at least one scope associated with the second set ofpermissions, one or more resources of the set of resources.
 19. Thesystem of claim 17, wherein the instructions when executed further causethe system to: generate the second set of permissions to only grantpermission for access corresponding to a set of actions performed withrespect to the first set of permissions.
 20. The system of claim 17,wherein the instructions when executed further cause the system to:analyze the second set of permissions to ensure that any changes inpermissions either result in a narrowing of the at least one scopeassociated with the first set of permissions, or do not violate otherpermissions of the second set of permissions.